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ABSTRACT 


The sometimes-held position that "vendor supplied" 
intercomputer networking protocols based upon the International 
Standards Organization’s Reference Model for Open System 
Interconnection are worth waiting for, in particular in 
preference to protocols based upon the ARPANET Reference Model 
(ARM), is shown to be fallacious. 


The paper is a companion piece to M82-47, M82-48, M82-50, 
and M82-51. 


THE ILLUSION OF VENDOR SUPPORT 


M. A. Padlipsky 


Introduction 


Even one or two members of the DoD Protocol Standards 
Technical Panel join with many others (including, apparently, 
some members of the DoD Protocol Standards Steering Group, and 
clearly, somebody at the GAO) in expressing a desire to "go with 
vendor-supported intercomputer networking protocols instead of 
using our own." The author’s view of the implications of this 
desire should be clear from the title of this paper. What 
evidence, then, is there to so stigmatize what is clearly a 
well-meant desire to save the Government money? 


Scope 


First, we must consider what is meant by "vendor-supported 
protocols." It can’t be just X.25, because that only gets you 
through the network layer whether you’re appealing to the 
International Standards Organization’s widely-publicized 
Reference Model for Open System Interconnection (ISORM) or to the 
unfortunately rather tacit reference model (ARM) to which the 
ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed. It 
also can’t be just X.25 and X.28/X.29 (even with X.75 tossed in 
to handle "internetting" and X.121 for addressing) because: 1. 
They don’t serve as a protocol suite for resource sharing (also 
known as OSI), but rather only allow for remote access [1]. 2. 
They (coming as they do from the Consultative Committee on 
International Telegraphy and Telephony--and including one or two 
other protocols, in reality) don’t even constitute the full 
protocol suite being worked on by the U. S. National Bureau of 
Standards, much less the somewhat different suite being evolved 
by ISO. So it must be a suite from NBS or ISO, and for present 
purposes we needn’t differentiate between them as their Reference 
Models are close enough to be shorthanded as the ISORM. 


Timeliness 


Realizing that we’re being asked to consider an 
ISORM-related protocol suite as what the vendors are expected to 
support has one immediate consequence which in some sense can be 
considered to dominate all of the other points to be raised: 
That is, the DoD procurement process entails quite long lead 
times. Yet the ISORM suite is by no means complete at present. 
Without prejudice to its 
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merits or demerits, only X.25 (as levels 1-3, and with some 
ambiguity as to what level X.75 belongs at) is as yet firmly in 
the ISORM suite (which it will be convenient to refer to as 
"TSORMS"), and there is even some doubt as to how firmly they’re 
there. (E.g., a British observer at a recent PSTP meeting 
assured the author that "We in the U.K. don’t believe X.25 is 
officially part of the ISORM.") There are proposals which have 
been circulating for some time at Level 4, and less far along 
through the international (or even national, remembering NBS) 
standardization process, ones at Level(s) 5-7. It must be noted 
that: 1. These are by and large "paper protocols" (that is, 
they have not been subjected to the test of actual use). 2. 
Even ISO and NBS’s warmest supporters acknowledge that the 
standardization process "takes years." So if the DoD is to avoid 
buying what might turn out to be a series of pigs in a series of 
pokes, it can’t wait for the ISORMS. 


On the other side of the coin, the DoD is letting 
intercomputer networking contracts right now. And, right now, 
there does exist a suite of protocols designed to the ARPANET 
Reference Model (ARMS, with no pun intended). Implementations of 
the ARMS already exist for a number of operating systems already 
in use in the DoD. Now, it is not argued that the ARMS protocols 
come "for free" in upcoming acquisitions (contractors fuss about 
the style of the available specifications, system maintainers 
fear incursions of non-vendor supplied code into operating 
systems, and so on), but it is unarguable that the ARMS can be 
procured significantly more rapidly than the ISORMS. (It is also 
unarguable that those who speak of their unwillingness to see the 
DoD "develop new protocols rather than employ international 
standards" haven’t done their homework; we’re not talking about 
new protocols in the ARMS, we’re talking about protocols that 
have been in real use for years.) 


Quality of Support 


The timeliness argument can lead to a counterargument that 
the ISORMS is "worth waiting for," though, so we’re not done yet. 
Let’s look further at what "vendor support" means. Clearly, the 
proponents of the position expect that vendors’ implementations 
of protocols will be in conformance with the Standards for those 
protocols. Given the nature of these specifications, though, 
what can we infer about the quality of support we can expect from 
the vendors? 


There are two problem areas immediately apparent: 
ambiguities and options. Let’s take ambiguities first. The 
following are some of the questions raised by knowledgable 
observers about the present state of the ISORMS: 
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Can an X.25 comm subnet offer alternate routing? (The 
answer depends on whether "DCE’s" are expected to 
follow X.25 between themselves. The situation is 
further complicated by the fact that some ISORM 
advocates don’t even include the Data Communication 
Elements in their depictions of the Model; this leads 
to the metaphorical question* "Are there parking 
garages between the highrises?") If you can conform to 
X.25 and not offer alternate routing--which certainly 
appears to be consistent with the spec, and might even 
be construed as required by it--the DoD’s inherent 
interest in "survivability" cannot be served by you. 


Can an X.75 internet offer alternate gatewaying? (The 
answer is almost surely no, unless the X.75 spec is 
re-written.) If not, again the DoD’s interest is not 
served. 


Does "Expedited Data" have semantics with regard to the 
L4-L5/L7 interface? (Not as I read the spec, by the 
way.) If not, the ISORMS lacks the ability to convey an 
"Qut-of-Band-Signal" to an Application protocol. (This 
leads to the metaphorical question, "What good is an 
SST if there's nobody on duty at the Customs Shed?") 


Must all layers be traversed on each transmission? 
(There are rumors of a new ISORM "null-layer" concept; 
it's not in the last version I looked at, however, and 
apparently the answer is yes at present.) If so, the 
DoD's inherent interest in efficiency/timeliness cannot 
be served. (This leads to the metaphorical question, 
"Are there elevators inside the highrises, or just 
staircases?") 


Can an implementation be in conformance with the ISORM 
and yet flout the prescription that "N-entities must 
communicate with each other by means of N-1 entities"? 
(Not as I read the spec.) If not, again 
implementations must be inefficient, because the 
prescription represents an inappropriate legislation of 
implementation detail which can only lead to 
inefficient implementations. 


* This and other metaphorical questions are dealt with at 
greater length in reference [2]. 
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6. Is each layer one protocol or many? (The point quoted 
in 5 would seem to imply the latter, but many ISORM 
advocates claim it’s the former except for L1 and L7.) 
If each layer is a "monolith", the DoD’s interest is 
not served because there are many circumstances in 
which applications of interest require different L1-3 
and L4 protocols in particular, and almost surely 
different L5 and L6 protocols. (Areas of concern: 
Packetized Speech, Packet Radio, etc.) 


The upshot of these ambiguities (and we haven’t exhausted 
the subject) is that different vendors could easily offer 
ISORMS’s in good faith which didn’t interoperate "off-the-shelf". 
Granted, they could almost certainly be fixed, but not cheaply. 
(It is also interesting to note that a recent ANSI X3T5 meeting 
decided to vote against acceptance of the ISORM as a 
standard--while endorsing it as valuable descriptively--because 
of that standards committee’s realization of just the point we 
are making here: that requiring contractual compliance with a 
Reference Model can only be desirable if the Reference Model were 
articulated with utter--and probably humanly 
unattainable--precision.) 


The area of options is also a source for concern over future 
interoperability of ISORMS implementations from different 
vendors. There’s no need to go into detail because the broad 
concern borders on the obvious: What happens when Vendor A’s 
implementations rely on the presence of an optional feature that 
Vendor B’s implementations don’t choose to supply? Somebody 
winds up paying--and it’s unlikely to be either Vendor. 


On the other side of the coin, the ARMS designers were all 
colleagues who met together frequently to resolve ambiguities and 
refine optionality in common. Not that the ARMS protocols are 
held to be flawless, but they’re much further along than the 
ISORMS. 


To conclude this section, then, there are grounds to suspect 
that the quality of vendor support will be low unless the price 
of vendor support is high. 


Nature of the Design Process 


The advantage of having colleagues design protocols touched 
on above leads to another area which gives rise to concern over 
how valuable vendor-supported protocols really are. Let’s 
consider how international standards are arrived at: 
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The first problem has to do with just who participates in 
the international standardization process. The author has 
occasionally chided two different acquaintances from NBS that 
they should do something about setting standards for membership 


on standards committees. The uniform response is to the effect 
that "They are, after all, voluntary standard organizations, and 
we take what we’re given." Just how much significance is 


properly attached to this insight is problematical. Even the 
line of argument that runs, "How can you expect those 
institutions which have votes to send their best technical people 
to a standards committee? Those are precisely the people they 
want to keep at home, working away," while enticing, does not, 
after all, guarantee that standards committees will attract only 
less-competent technicians. There are even a few Old Network 
Boys from the ARPANET involved with the ISORM, and at least one 
at NBS. However, when it is realized that the rule that only 
active implementers of TCP were allowed on the design team even 
precluded the present author’s attendance (one of the oldest of 
the Old Network Boys, and the coiner of the phrase, at that), it 
should be clear that the ARMS enjoys an almost automatic 
advantage when it comes to technical quality over the ISORMS, 
without even appealing to the acknowledged-by-most politicization 
of the international standards arena. 


what, though, of the NBS’s independent effort? They have 
access to the experienced designers who evolved the ARMS, don’t 
they? One would think so, but in actual practice the NBS’s 
perception of the political necessities of their situation led 
one of their representatives at a PSTP (the Department of Defense 
Protocol Standards Technical Panel) meeting to reply to a 
reminder that one of the features of their proposed Transport 
Protocol was a recapitulation of an early ARPANET Horror Story 
and would consume inordinate amounts of CPU time on participating 
Hosts only with a statement that "the NBS Transport Protocol has 
to be acceptable as ECMA [the European Computer Manufacturer’s 
Association] Class 4." And even though NBS went to one of the 
traditional ARPANET-related firms for most of their protocol 
proposals, curiously enough in all the Features Analyses the 
author has seen the features attributed to protocols in the ARMS 
are almost as likely to be misstated as not. 


The conclusion we should draw from all this is not that 
there’s something wrong with the air in Gaithersburg, but rather 
that there’s something bracing in the air that is exhaled by 
technical people whose different "home systems’" idiosyncracies 
lead naturally to an intellectual cross-fertilization, on the one 
hand, and a tacit agreement that "doing it right" takes 
precedence over "doing it expediently," on the other hand. (If 
that sounds too corny, the reader should be aware that the author 
attended a large number of 
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ARPANET protocol design meetings even if he wasn’t eligible for 
TCP: in order to clarify our Host-parochial biases, we screamed 
at each other a lot, but we got the job done.) 


One other aspect of the international standardization 
process has noteworthy unfortunate implications for the resultant 
designs: However one might feel on a technical level about the 
presence of at least seven layers (some seem to be undergoing 
mitosis and growing "sublayers"), this leads to a real problem at 
the organizational--psychological level. For each layer gets its 
own committee, and each committee is vulnerable to Parkinson’s 
Law, and each layer is in danger of becoming an expansionist 
fiefdom .... If your protocol designers are, on the other hand, 
mainly working system programmers when they’re at home--as they 
tend to be in the ARPANET--they are far less inclined to make 
their layers their careers. And if experience is weighted 
heavily--as it usually was in the ARPANET--the same designers 
tend to be involved with all or most of the protocols in your 
suite. This not only militates against empire building, it also 
minimizes misunderstandings over the interfaces between 
protocols. 


"Space-Time" Considerations 


At the risk of beating a downed horse, there’s one other 
problem area with the belief that "Vendor supplied protocols will 
be worth waiting for" which really must be touched on. Let's 
examine the likely motives of the Vendors with respect to 
"space-time" considerations. That is, the system programmer 
designers of the ARMS were highly motivated to keep protocol 
implementations small and efficient in order to conserve the very 
resources they were trying to make sharable: the Hosts’ CPU 
cycles and memory locations. Are Vendors similarly motivated? 


For some, the reminder that "IBM isn’t in business to sell 
computers, it’s in business to sell computer time" (and you can 
replace the company name with just about any one you want) should 
suffice. Especially when you realize that it was the traditional 
answer to the neophyte programmer’s query as to how come there 
were firms making good livings selling Sort-Merge utilities for 


System X when one came with the operating system (X = 7094 and 
the Operating system was IBSYS, to date the author). But that’s 
all somewhat "cynical", even if it’s accurate. Is there any 


evidence in today’s world? 


Well, by their fruits shall you know them: 1. The feature 
of the NBS Transport Protocol alluded to earlier was an every 
15-second "probe" of an open connection ("to be sure the other 
guy’s still 
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there"). In the early days of the ARPANET, one Host elected to 
have its Host-Host protocol (popularly miscalled "NCP" but more 
accurately AH-HP, for ARPANET Host-Host Protocol) send an echo 
("ECO") command to each other Host each minute. The "Network 
Daemon" on Multics (the process which fielded AH-HP commands) 
found its bill tripled as a result. The ECMA-desired protocol 
would generate four nuisance commands each minute--from every 
Host you’re talking to! (The "M", recall, is for 
Manufacturers.)* 2. X.25 is meant to be a network interface. 
Even with all the ambiguities of the ISORM, one would think the 
"peer" of a "DTE" (Host) X.25 module (or "entity") would be a 
"DCE" (comm subnet processor) X.25 module. But you can also "talk 
to" at least the foreign DCE’s X.25 and (one believes) even the 
foreign DTE’s; indeed, it’s hard to avoid it. Why all these 
apparently extraneous transmissions? CCITT is a body consisting 


of the representatives of "the PTT’s"--European for State-owned 
communications monopolies. 3. The ISORM legislates that 
"N-entities" must communicate through "N-1 entities." Doesn't 


that make for the needless multiplication of N-1 entities? Won't 
that require processing more state information than a closed (or 
even an open) subroutine call within level N? Doesn’t anybody 
there care about Host CPU cycles and memory consumption? 


Note particularly well that there is no need to attribute 
base motives to the designers of the ISORMS. Whether they’re 
doing all that sort of thing on purpose or not doesn’t matter. 
What does matter is that their environment doesn’t offer positive 
incentives to design efficient protocols, even if it doesn’t 
offer positive disincentives. (And just to anticipate a likely 
cheap shot, TCP checksums are necessary to satisfy the design 
goal of reliability; ECMA four pings a minute is[/was] 
unconscionable.) 


TANSTAAFL 


We’re very near the end of our analysis. Readers familiar 
with the above acronym might be tempted to stop now, though there 
are a few good points to come. For the benefit of those who are 
not aware: "There Ain’t No Such Thing As A Free Lunch." 
Achieving interoperability among vendor-supplied protocol 
interpreters won’t come for free. For that matter, what with all 
this "unbundling" 


* Rumor has it that the probes have since been withdrawn from 
the spec. Bravo. However, that they were ever in the spec is 
still extremely disquieting--and how long it took to get them 
out does not engender confidence that the ISORMS will be 
"tight" in the next few years. 
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stuff, who says even the incompatible ones come for free? You 
might make up those costs by not having to pay your maintenance 
programmers to reinsert the ARMS into each new release of the 
operating system from the vendor, but not only don’t good 
operating systems change all that often, but also you'll be 
paying out microseconds and memory cells at rates that can easily 


add up to ordering the next member up in the family. In short, 
even if the lunch is free, the bread will be stale and the cheese 
will be moldy, more likely than not. It’s also the case that as 


operating systems have come to evolve, the "networking" code has 
less and less need to be inserted into the hardcore supervisor or 
equivalent. That is, the necessary interprocess communication 
and process creation primitives tend to come with the system now, 
and device drivers/managers of the user’s own devising can often 
be added as options rather than having to be built in, so the 
odds are good that it won’t be at all hard to keep up with new 
releases anyway. Furthermore, it turns out that more and more 
vendors are supplying (or in process of becoming able to supply) 
TCP/IP anyway, so the whole issue of waiting for vendor support 
might well soon become moot. 
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